Historically, various mainframe application developers developed their own applications (hereinafter referred to as “legacy applications”) and their own application programming interfaces (APIs) by which programs communicated with other programs. This has created an environment where a user or programmer must learn the details of each vendor's transactional processing system in order to use it. A programmer working with a particular transactional processing system must custom design transactional programs consistent with the vendor-specific protocols for that transactional processing system. As a general matter, transactional programs are executed by a processing mechanism, but software protocols may differ from vendor to vendor. If the same transactional program is to be used later in conjunction with another transaction support product, the program must be modified to comply with the next vendor's protocols.
The most widely used transaction processing system in the world today is a product of IBM, called CICS. CICS was introduced in the late 1960s, and has grown steadily in usage around the world. CICS is a registered trademark of IBM.
With the advent of distributed computing, attempts have been made to integrate legacy applications with distributed applications and systems. In one solution, a proxy program is used to interface between a legacy application program and a client application. This is illustrated in FIG. 1A. FIG. 1A is a block diagram that illustrates using a proxy program to interface with a legacy application. As shown in FIG. 1A, a client application 100 communicates with a server 110 via a network 105 such as the Internet/Intranet. A network interface 115 of server 110 handles communications between the client application 100 and the server 110. A proxy program 120 is required for each legacy application 125 on the server 110. The proxy program 120 receives a request from the client application 100, converts the request into a form that the legacy application 125 expects, accepts result data provided by the legacy application 125, converts the result data into a format required by the client application 100, and returns the converted result data to the client application 100. Thus, the proxy program contains both metadata describing the data format, and the logic responsible for data translation and execution of the legacy application program. Unfortunately, this solution requires writing a separate proxy program 120 for each legacy application 125. This means that changing the runtime environment often requires recoding the proxy program 120, often at significant expense.
In another solution, a legacy application program is modified to interface with a client application. This is illustrated in FIG. 1B. FIG. 1B is a block diagram that illustrates interfacing with a legacy application by modifying the legacy application. As shown in FIG. 1B, a client application 150 communicates with a server 160 via a network 155 such as the Internet. A network interface 165 of server 160 handles communications between the client application 150 and the server 160. The network interface 165 communicates directly with a legacy application 170 that has been modified to accept input data and return result data in a format acceptable to the client application 150. Unfortunately, this solution requires recoding each legacy application program 170.
Accordingly, a need exists in the art for a solution that provides a Service Oriented Architecture (hereinafter referred to as “SOA”) interface to legacy applications without requiring coding changes to the legacy applications and without requiring the coding of proxy programs. A further need exists for such a solution that requires relatively less coding upon changing the interface between a client application and the server where the legacy application program resides. Yet a further need exists for such a solution that requires relatively less knowledge of communication protocols or programming languages in order to provide the SOA interface.